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Art Unit: 3692 

DETAILED ACTION 

The following is Examiner's response to Applicant's amendment received 04/02/2008 
stemming from Examiner's Office Action dated 02/01/2008. 



Status of the Claims 

As per Applicant's response, Examiner acknowledges that Applicant (1) amended Claims 
1, 2 & 4-12, (2) cancelled Claim 3, and (3) submitted amendments to his/her Specification. As 
such, Claims 1, 2 & 4-12 are currently pending. 



Response to Remarks/Arguments 
Minor Claim Objections & Specification Objections 
In view of Applicant's Amendments, Examiner withdraws all objections to Applicant's 
Claims and Specification made in the Office Action of 02/01/2008. 



Statutory Grounds of Rejection 

The text of those sections of Title 35, U.S. Code not included in this action can be found 
in a prior Office action. 

Claim Rejections - 35 USC § 112-l st Paragraph 
Claims 9-12 were rejected under 35 U.S.C. 1 12, first paragraph, as failing to comply with 
the written description requirement. 

As per Claim 9, Applicant states that the original disclosure teaches a network element 
"which interacts with a user terminal, requests and accounting server to deposit an 
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amount of credit to an account associated to the user terminal, receives an 
acknowledgement of the request, and deposits the amount of credit on the account 
associated to the user terminal" [Applicant's Response, page 19, lines 3-6]. Here, 
Applicant asserts that "inherent in the original disclosure is the required structure to 
perform said functions. . ." [Applicant's Response, page 19, lines 7-8]. Regardless, 
Examiner notes that his Office Action stated "that Applicant does not define a "network 
element". Under a broadest reasonable interpretation, "software" and "people" are 
elements of a network..." [Office Action, page 6, lines 16-18]. As such, structure for an 
apparatus claim does not necessarily flow from the functional limitations cited to by 
Applicant. A person could perform all the steps recited (e.g. interacts, requests, receives, 
deposits). 

As per Claims 10, Applicant states that the original disclosure teaches an "accounting 
server which receives a message from a network element and returns an 
acknowledgement to the network element" [Applicant's Response, page 19, lines 14-15]. 
Here, Applicant assets that "inherent in the original disclosure, is the required structure to 
perform said functions..." [Applicant's Response, page 19, lines 16-17]. Regardless, 
Applicant only states functional limitations of a structure (i.e. accounting server) but does 
not indicate particular structure of said accounting server. To clarify the record, 
Examiner suggests that Applicant indicate what particular structure said accounting 
server has which would have been known to one of ordinary skill in the art, at the time 
the invention was made. 
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As per Claims 1 1 & 12, Applicant invokes 35 USC §1 12-6* paragraph by (1) utilizing 
the phrase "means for", (2) modified by functional language, (3) without an indication of 
sufficient structure, materials, or acts, in the claim, to achieve those functions. In this 
vein, Claims 1 1 & 12 would ordinarily be construed to cover the corresponding structure, 
material or acts disclosed in the specification and equivalents thereof However, 
Applicant's specification does not describe any explicit structure, material or acts as 
associated with each particular "means for" clause of the claims. [Applicant only provides 
functional support from his/her Specification]. This raises an ambiguity issue (e.g. what 
"means" in particular accomplishes the functional limitation). ["[Structure disclosed in 
the specification is corresponding structure only if the specification or prosecution 
history clearly links or associates that structure to the function recited in the claim. This 
duty to link or associate structure to function is the quid pro quo for the convenience of 
employing 1 12, paragraph 6." (emphasis added) & "If no definition (e.g. link) is 
provided, some judgment must be exercised in determining the scope of the limitation." 
(see MPEP 2182, parenthetical added)]. As such, without a direct link, Examiner will 
interpret all claim limitations as reading on any prior art means which is capable of 
performing the specified functions under a broadest reasonable interpretation. 



Claim Rejections - 35 USC § 112-2 nd Paragraph 

In view of Applicant's Amendments, Examiner withdraws all rejections under 35 USC 
§ 1 12-2 nd Paragraph made in the Office Action of 02/01/2008. 



Application/Control Number: 1 0/5 1 8,242 Page 5 

Art Unit: 3692 

Claim Rejections - 35 USC § 103 

Applicant's arguments filed 04/02/2008 have been fully considered but they are not 
persuasive. Please see the respective comments below and the rejections that follow. 

Claims 1, 4 & 6-12 were rejected under 35 U.S.C. 103(a) as being unpatentable over Hilt 
et al [5,465,206] in view of Tsuda [2002/0065785]. 

After reciting the text of Claims 1 & 9-12 [Applicant's Response, pages 23-25], 
Applicant comments that "the DIAMETER protocol can be adopted for online charging 
purposes. Therefore, online charging is provided for without involving a third party, such 
as an independent vendor" [Applicant's Response, page 25, lines 17-19]. Here, Examiner 
notes that Tsuda (785) supports a "server device carrying] out a processing for providing 
the desired accounting service according to the ...request" [see Abstract] and suggests 
further "authentication and accounting for the other needs that may arise on the mobile 
nodes" [paragraph 5, i.e. "various purposes" (paragraph 19)] including "for credit 
payment of charges for purchases" [paragraph 16, "purchasing goods at electronic shops" 
(paragraph 65)]. Here, Tsuda ('785) discusses interactions of the "mobile node device" 
with the "AAA server" for transactions using "AAA functions" without the need for 
involving a third party, [see paragraph 55] including functionality to "automatically 
withdraw[] from an account" [paragraph 69]. 

As per Claims 1, & 9-12, Examiner generally points Applicant to the rejection that 
follows. However, Examiner notes that, Hilt et al ('206) does teach Applicant's amended 
limitation comprising a "receiver [which] receives a request message from a network 
element" [see column 2, lines 48-54, Here, Hilt et al ('206) discloses a bill pay system 



Application/Control Number: 1 0/5 1 8,242 Page 6 

Art Unit: 3692 

operator (i.e. network element) that sends a payment request (e.g. that said bill pay 
system operator received from a party) to a central computer/server which "obtain[s] 
funds" to "pay the biller" (column 2, lines 48-57). Given that the payment request is 
"sent to" the computer/server, it necessarily comprises a "receiver"]. Further, Applicant's 
reduction of Hilt to "a payment of bills between a consumer and a biller" [Applicant's 
Response, page 28, line 6] or "between two terminals" [Applicant's Response, page 28, 
line 13] is too strict. In an obviousness type rejection, Examiner is providing evidence of 
what one of ordinary skill in the art would understand regarding payments between 
parties (i.e. ordering money transfers between accounts) and the systems and processes 
known at the time of Applicant's invention. Here, Examiner disagrees that the 
underlying method of Applicant's invention are "clearly different" [Applicant's Response, 
page 28, line 8]. Merely a request for payment is made and a server implements said 
request. Despite potentially distinct signaling [Applicant's Response, page 28, line 7] 
being involved, distinct signaling is not necessarily non-obvious if said signaling would 
predictably be utilized by one of skill in the art at the time of Applicant's invention for 
such a particular purpose (i.e. including data with the signals associated with transferring 
money). Next, Hilt ('206) does disclose "a network element interacting with a terminal" 
[Applicant's Response, page 28, line 19-21, see Hilt ('206), Abstract, i.e. bank are an 
agent for the consumer/biller which interacts with the payment network]. 
In response to Applicant's comments regarding DIAMETER protocol [Applicant's 
Response, page 29, beginning line 9], Examiner may admit that Hilt ('206) does not 
explicitly disclose limitations as specifically claimed by Applicant. However, Hilt ('206) 
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despite Applicant's contention, does portray suggestion for the use of "protocols" and 
other limitations [see Office Action, page 8, lines 12-13 & page 9, lines 4-5, & page 9, 
lines 17-18]. Here, Tsuda ('785) does remedy the deficiencies of Hilt ('206) by 
specifically suggesting the use of DIAMETER protocol for "various purposes" 
[paragraph 19] including functionality to "automatically withdraw[] from an account" 
[paragraph 69]. The fact that Tsuda (785) may have contemplated an older version of 
DIAMETER is irrelevant given that the suggestion to use DIAMETER is present and one 
of skill in the art would appreciate substitution of a new/modified version for the old (i.e. 
updates and revisions of standards arc well established in the arts) in an obviousness type 
analysis. Lastly, Tsuda ('785) does not explicitly contemplate crediting an account, but it 
does contemplate debiting an account [paragraph 69]. Here, one of skill in the art would 
appreciate that if debiting is available, crediting would also be contemplated and 
similarly implemented. 

In response to Applicant's argument that Applicant's "[added] features" [Applicant's 
Response, page 31, line 4] to a modified version of DIAMETER distinguish it from the 
art of record, Examiner points Applicant to an Applicant cited reference by Niemi [see 
Applicant's Specification, page 8, lines 26-32] which discloses the basics/introduction to 
DIAMETER as known to one of skill in the art at the time of Applicant's invention. 
Here, Niemi evidences that "Diameter protocol is actually split into two parts: the 
Diameter Base Protocol, and the Diameter Applications" [Niemi, page 26, last 
paragraph]. Further, Niemi teaches that the "base protocol... deliver[s] the Diameter data 
units, negotiating capabilities... [whereas a] Diameter application defines the application 
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specific functions and data units" [Niemi, page 26-27, continuing paragraph]. Here, 
"route entries [may] have a different destination depending on the Diameter 
Application. . . [where] the message processing can follow different procedures depending 
on the message" [Niemi, page 28, first paragraph] and "particular service[s are] defined 
by the corresponding Diameter application" [Niemi, page 28, paragraph 6]. In this vein, 
Niemi teaches that "Diameter messages consist of a Diameter header, followed by some 
number of Diameter Attribute Value Pairs (A VP)" [Niemi, page 31, paragraph 1]. Here, 
command flags "specify the semantics associated with the particular Diameter message" 
and command code "indicates the command associated with the Diameter message 
[where] Command-Code field[s] can be populated either with IETF standard commands, 
or with vendor specific Command-Codes. Standard commands are either commands in 
the Diameter base protocol, or specific commands of a Diameter application." [Niemi, 
page 31, paragraphs 2 & 3]. Further, "AVPs contain. ..information elements, as well as 
routing, security, and configuration information elements that are relevant to the 
particular Diameter request or answer message. [Niemi, page 3 1 , last paragraph]. Here, 
AVP flags "carry information on how the attribute should be handled by the receiving 
end." [Niemi, page 32, paragraph 2]. In sum, "[e]ach individual Diameter application 
defines its own authentication and authorization Command-Codes and AVPs. The 
accounting application described by the base protocol is shared among the applications - 
only the accounting AVPs are application specific." [Niemi, page 33, paragraph 4]. 
As such, Niemi describes a Diameter base protocol which is intended to be modified via 
various Diameter applications to accomplish various services. Here, one of skill in the art 
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would appreciate that base protocol and application specific command codes could be 
derived for particular services such as "identifying a request as a request for depositing an 
amount to an account" including defining application specific AVPs to 'carry 
information' on the handling of attributes (e.g. source, amount, account number, terminal 
ID, etc.). Niemi admits that each Diameter Application defines its own command codes 
and AVPs [above]. Lastly, Niemi suggests that "[n]ew Diameter applications should be 
created." [Niemi, page 42, number 4]. 

In view of the above suggestions and motivations, Applicant's modification of the 
Diameter base protocol to accomplish a well known task (i.e. transferring money) is 
predictable and technically feasible. Tsuda's ('785) suggestion for using DIAMETER for 
"various purposes" [paragraph 19] including transferring money [paragraph 69] is clearly 
relevant under an obviousness type rejection despite the fact that Tsuda (785) may not 
explicitly disclose the DIAMETER modifications contemplated by Applicant. Applicant 
admits that "Diameter is an AAA protocol" [Applicant's Specification, page 5, line 14], 
thus one of skill in the art would look to Tsuda (785) as relevant prior art. 
As per Claims 4 & 6-8, Applicant did not individually address said Claims but merely 
concluded them, without support, as allowable based on Claim 1 reasoning. 



Claim 2 was rejected under 35 U.S.C. 103(a) as being unpatentable over Hilt et al 
[5,465,206] in view of Tsuda [2002/0065785] and further in view of Tubinis [2003/0014367]. 
As per Claim 2, Applicant did not individually address the limitations of Claim 2 but 
merely concluded it as allowable based on Claim 1 reasoning. 
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Claim 5 was rejected under 35 U.S.C. 103(a) as being unpatentable over Hilt et al 
[5,465,206] in view of Tsuda [2002/0065785] and further in view of Official Notice. 

As per Claim 5, Applicant traversed the Official Notice without adequate support and 
merely concluded it as allowable based on Claim 1 reasoning. 

In summary, Examiner basically maintains his previous grounds of rejection in view of 
background information (referenced in Applicant's original disclosure, page 8) which evincing 
what one of ordinary skill in the art, at the time of Applicant's invention would have known 
and/or been motivated to do regarding both modifying and adding data and/or functionalities to 
existing DIAMETER protocol. 

Response to Amendments 
Minor Claim Objections 

Claim 1 is objected to because of the following informalities: 

1. As per Claims 1, Examiner suggests "to said account" in lieu of "on said account" 
in two instances. Further, Examiner suggests "wherein said sent request", in two 
instances, in lieu of "wherein said sending a request" to avoid antecedent basis 
issues. Next, "a request" of the second wherein clause already holds antecedent 
basis. Examiner suggests similar language to the sending limitation. Lastly, 
Applicant should be consistent in his/her use of "the" or "said" for clarity. 

Appropriate correction is required. 
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Claim Rejections - 35 USC § 103 

Claims 1, 4, 6-12 are rejected under 35 U.S.C. 103(a) as being unpatentable over Hilt et 
al (5,465,206) in view of Tsuda [2002/0065785]. 

As per Claim 1 , Hilt et al ('206) teaches the method as follows: 

interacting with a user terminal [Abstract, Hilt et al ('206) indicates that apparatus used can be 
"an ATM, [a] PC or [a] telephone keypad" etc.] subscribed to a communication network 
[Abstract, "payment network" & column 1, line 65, "bill pay service bureau"] , wherein said 
interacting yields an indication of at least (a) whether a credit is to be deposited on an account [Abstract, 
"consumers receive bills from participating billers (paper/mail bills, e-mail notices, 
implied bills for automatic debts)". Here, Examiner noted, uncontested, that one of skill 
in the art would appreciate that a credit is to be deposited to the biller's account. Here, 
the received bill is the indication.] associated to said user terminal [Examiner notes that said 
bill pay system works via PC interaction and that "payment origination is usually done 
electronically" (column 2, lines 4-5 & see column 2, line 15). Association would be 
necessary for electronic payment via the terminal.], (b) an amount of credit to be deposited, and 
(c) a source of the credit, [Hilt et al ('206) discloses using "biller data" (column 2, line 10) to 
ultimately "credit the amount [due] to the consumer's account with the biller. (i.e. biller's 
account)" (column 2, lines 13-15, parenthetical added). Here, Examiner noted, 
uncontested, that said service indicates the source of funds as the "consumer's bank 
account" (column 2, line 9) either encoded on the instrument (column 2, line 1 1) or 
"included with the [electronic] transfer" (column 2, line 16).] 

Next, Hilt ('206) teaches sending a request to said source to deposit said amount on said account 
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[Examiner noted, uncontested, that said requesting (i.e. sending) is inherent since any 
account holder must "order" his or her bank or payment service to transfer funds. 
Regardless, Hilt et al ('206) discloses the practice of "pre-authorization" where "billers 
get[] pre-authorization from consumers to [directly] submit debit requests to consumer's 
bank or a service" (column 3, lines 27-29, parenthetical added). As such, with pre- 
authorization, one owed (payee) can request "said amount of credit" automatically from 
"said source of deposit" (payor account) to their payee account. This known method 
avoids a period of waiting for said payor to authorize or order his bank to make 
payment.] 

However, Hilt et al ('206) does not explicitly disclose: wherein sending a request is based on a 
DIAMETER protocol, Regardless, Hilt ct al ('206) docs teach "participants agree[ing] to a 
set of protocols [for] data exchange and messaging [] as well as operating regulations" 
[column 10, lines 41-43]. In this vein, Applicant admits as known, that "DIAMETER is 
an AAA (Authentication, Authorization, and Accounting) protocol specified in IETF." 
[Applicant's Specification, page 5, lines 16-18]. Nevertheless, Tsuda ('785) teaches the 
use of AAA protocols in "a mobile communication system" for the transmission of an 
"authentication and accounting request for requesting a desired accounting service at an 
AAAH server". As such, it would have been obvious to one of ordinary skill in the art, at 
the time of Applicant's invention, to modify Hilt et al ('206) to include DIAMETER as 
the protocol of use in its money transfer request. One would have been motivated to do 
so given that DIAMETER is a known protocol and Tsuda ('785) suggests its use for 
"authentication and accounting for the other needs that may arise on the mobile nodes" 
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[paragraph 5, i.e. "various purposes" (paragraph 19)] including "for credit payment of 
charges for purchases" [paragraph 16, "purchasing goods at electronic shops" (paragraph 
65)]. Here, Tsuda ('785) discusses interactions of the "mobile node device" (e.g. user 
terminal) with the "AAA server" for transactions using "AAA functions" without the 
need for involving a third party, [see paragraph 55] including functionality to 
"automatically withdraw[] from an account" [paragraph 69]. 

Further, Hilt et al ('206) does not explicitly disclose wherein said sending a request comprises 
generating a DIAMETER request message identifying the request as a request for depositing the amount to 
the account, Regardless, Hilt et al ('206) does disclose a biller and the biller's bank (service 
provider) agreeing "on a data transfer protocol for transferring A/R (accounts receivable, 
i.e. money owed) data" [column 18, lines 66-67, (parenthetical added)]. Further, see 
biller pre-authorization above. As such, it would have been obvious to one of ordinary 
skill in the art, at the time of Applicant's invention, to modify Hilt et al ('206) to include a 
DIAMETER request message identified as a request for deposit of an amount to an 
account. See use of DIAMETER discussion above and Examiner's discussion of the 
Niemi reference in the remarks section above. One would have been motivated to do so 
given that a biller using a payment network would necessarily be required to provide 
information where a payment service needs to collect funds and what amount (e.g. 
accounts receivable). Said payment service would then logically utilize such information 
to send requests via such agreed upon protocols. Stated another way, the protocol 
utilized would provide/contain such a command and data necessary to implement the 
command (i.e. request for money transfer). 
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Further, Hilt et al ('206) does not explicitly disclose wherein said generated DIAMETER 
request message further comprises a first attribute value pair identifying the user terminal to the account. 
Regardless, Hilt et al ('206) does disclose the use of a "unique biller reference number 
(BRN) [column 10, lines 47-48] and "pointers" [column 10, line 58] which identify [y]the 
biller to the payment network" [column 10, lines 47-49] and the "C-B account numbers" 
(customer's account number with the biller) [column 10, line59]. As such, it would have 
been obvious to one of ordinary skill in the art, at the time of Applicant's invention, to 
modify Hilt et al ('206) to include a DIAMETER request message with an attribute value 
pair for linking a terminal to the account for credit of funds. See use of DIAMETER 
discussion above and Examiner's discussion of the Niemi reference in the remarks section 
above. One would have been motivated to do so because the use of actual account 
numbers would disclose personal information and the use of an alternate identifier, 
including an attribute value pair, pointers, or unique identification numbers would avoid 
this issue and be more secure, [see also column 2, line 10, "encoding the consumer's bank 
account number"]. Further, the defining of AVPs for specific Diameter applications was 
known at the time of Applicant's invention [See remarks section above.]. 
As per Claim 4 , Hilt et al ('206), as modified, teaches the method of Claim 1 above. 
However, Hilt et al ('206) does not explicitly disclose said generated DIAMETER request 
message further comprises: a second attribute value pair identifying said source; and a third attribute value 

pair identifying the amount. Regardless, Hilt et al ('206) does disclose the identification of 
data via "a bar code, or other mechanically or electronically readable form'" [column 1, 
lines 45-6]. In this vein, Hilt et al ('206) explicitly notes this data to be "account number, 
amount due", [column 1, lines 40-41]. Further, Hilt et al ('206) teaches "encoding the 



Application/Control Number: 1 0/5 1 8,242 Page 1 5 

Art Unit: 3692 

consumer's bank account number" with "the biller and MICR data" [column 2, lines 10- 
11]. Here, Examiner notes that check amounts are commonly known to be encoded in a 
MICR line. As such, it would have been obvious to one of ordinary skill in the art, at the 
time of Applicant's invention, to modify Hilt et al ('206) to include a second attribute 
value pair for identifying the source of funds and a third attribute value pair for 
identifying the amount of funds to be deposited. One would have been motivated to do 
so for security purposes and to avoid the disclosure of customer information, especially 
given the use of outside "operations for remittance processing" [column 1, line 35]. 
Further, such attribute value pairs would further "uniquely identify the consumer" in 
biller records, [column 3, line 51]. Lastly, the defining of AVPs for specific Diameter 
applications was known at the time of Applicant's invention [See remarks section]. 
As per Claim 6 , Hilt et al ('206), as modified, teaches the method of Claim 1 above. 
Further, Hilt et al ('206) teaches acknowledging, by said source, said request. ["Bank C 
(consumer's bank) then submits an electronic transaction, a payment message, into a 
payment network directed to Bank B (biller's bank), (see column 10, lines 64-66). Here, 
Examiner notes that Bank C's sending of a payment message obligates it to make 
payment through the payment network to Bank B by debiting their consumer's account, 
(column 11, lines 10-14). Thus, said message is acknowledgment that adequate funds 
were available in consumer's account and said request is being processed.]. 
As per Claim 7 , Hilt et al ('206), as modified, teaches the method of Claim 6 above. 
Further, Hilt et al ('206) teaches depositing said amount to said account upon receiving an 
acknowledgment, ["bank B receives a net position from the payment network and credits 
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biller B's bank account" (column 11, line 14) logically using "BRNs and/or C-B account 
numbers" (column 10, lines 53-54).]. 

As per Claim 8 , Hilt et al ('206), as modified, teaches the method of Claim 7 above. 
Further, Hilt et al ('206) teaches informing said user terminal of the amount deposited to said 
account, [see Abstract, "biller's bank... provides A/R data to biller" & column 4, lines 37- 
38, "account statement. . . .('A/R') data file". Otherwise, biller would send an "('NSF') 
notice", column 4, line 40.]. 
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As per Clam 9 , Hilt et al ('206) teaches the apparatus as follows: 
an interaction unit ["means of data and message processing" (column 12, line 54, (e.g. 
Examiner interprets this as a computer processor, display, modem, etc. as known in the 
art) and "computer systems. . .which operate the bank component of the payment 
network" (column 12, line 56)] configured to interact with a user terminal subscribed to a 
communication network, wherein said interaction unit is further configured to yield an indication of at least 
(a) whether a credit is to be deposited on an account associated to said user terminal, (b) an amount of 
credit to be deposited, and (c) a source of the credit; [Here, Examiner asserted, uncontested, that 
computers are inherently configured/programmed to perform the methods desired, such 
as these limitations as discussed in Claim 1 above.] 

Next, Hilt et al ('206) teaches a requesting unit [a payment network comprising "[bank] 
computer systems [connected] to computer systems at other banks through an [access 
point] device" (column 11, lines 3-4) & "e-mail notices, implied bills for automatic 
debts" (column 10, line 46)] configured to send a request to said source to deposit said amount on 
said account [Here, Examiner asserted, uncontested, that computers are inherently 
configured/programmed to perform the methods desired, such as this limitation as 
discussed in Claim 1 above.] 

Next, Hilt et al ('206) teaches a depositing unit [column 16, lines 35-37 & 31, Part of the 
payment system is a "settlement subsystem... transfers of funds between accounts" & 
"settlement account for Bank B" & Abstract, "biller's bank. . .releases the funds to the 
biller"] configured to deposit the amount to the account. Surely a computer could be so 
configured. 

However, Hilt et al ('206) does not explicitly disclose: wherein said request is based on the 
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DIAMETER protocol, AND wherein said requesting unit is further configured to generate a DIAMETER 
request message identifying the request as a request for depositing the amount to the account, AND 
wherein said generated DIAMETER request message further comprises an attribute value pair identifying 
the user terminal to the account. Regardless, Examiner reiterates that Hilt et al ('206) teaches 
a system implementing "pre-agreed protocols" [column 12, lines 46-47]. Further, 
Applicant's admission of the known DIAMETER protocol as well as the disclosure of the 
Niemi reference discussed in the remarks section above in combination with the 
teachings of Tsuda ('785) for the use of AAA protocol in communication networks 
makes said limitations obvious for implementation by an apparatus under the logic as 
outlined in Claim 1 above. One would have been motivated to do so for efficiency and to 
avoid computational or number transfer errors. Lastly, Examiner asserted, uncontested, 
that computers are inherently configured/programmed to perform the methods desired, 
such as these limitations as discussed in Claim 1 above.] 

Next, Hilt et al ('206) does not explicitly disclose a receiver configured to receive an 
acknowledgment of said request. Regardless, Hilt et al ('206) does disclose to ability to 
"receive the bill payment order" [column 10, line 63] as well as "billers. . .submitting] 
debit requests to consumer's bank" [column 3, lines 27-29] with "banks connecting] their 
computer systems to computer systems at other banks" through a payment network, 
[column 11, lines 1-3]. Regardless, Tsuda ('785) teaches a "communication processing 
function, a communication interface, a memory device, and an input/output device" 
[paragraph 65] for receiving Diameter requests. As such, it would have been obvious to 
one of ordinary skill in the art, at the time of Applicant's invention, to modify Hilt et al 
('206) to include a receiver configured to receive an acknowledgement of said request. 
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One would have been motivated to do so given that electronic requests are more cost 
effective than formal paper requests, especially considering the potential large number of 
requests (e.g. often preauthorized) for any given biller. Surely a computer could be so 
configured, (e.g. email). 

As per Claim 10 , Hilt et al ('206) teaches the apparatus as follows: 

a receiver configured lo receiv e a request message from a network element to deposit an amount of credit 
to an account associated to a user terminal subscribed to a communication network, [Hilt et al ('206) 
discloses a bill pay system operator (i.e. network element) that sends a payment request 
(e.g. that said bill pay system operator received from a party) to a central computer/server 
operated by the system which "obtain funds" to "pay the biller" (column 2, lines 48-57). 
Given that the payment request is "sent to" the computer/server, said computer 
necessarily comprises a "receiver".] 

However, Hilt et al ('206) does not explicitly disclose: wherein said request message is based on 
a DIAMETER protocol, AND wherein said DIAMETER request message identifies the request as a request 
for depositing the amount to the account, AND wherein said received DIAMETER request message further 
comprises an attribute value pair identifying the user terminal to the account; Regardless, Examiner 
reiterates that Hilt et al ('206) teaches a system implementing "pre-agreed protocols" 
[column 12, lines 46-47]. Further, Applicant's admission of the known DIAMETER 
protocol as well as the disclosure of the Niemi reference discussed in the remarks section 
above in combination with the teachings of Tsuda ('785) for the use of AAA protocol in 
communication networks makes said limitations obvious for implementation by an 
apparatus under the logic as outlined in Claim 1 above. One would have been motivated 
to do so for efficiency and to avoid computational or number transfer errors. Lastly, 
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Examiner asserted, uncontested, that computers are inherently configured/programmed to 
perform the methods desired, such as these limitations as discussed in Claim 1 above.] 
Lastly, Hilt et al ('206) does not explicitly disclose an acknowledging unit configured to return 
an acknowledgment to the network element, wherein the acknowledgment is based on the DIAMETER 
protocol. Regardless, Hilt et al ('206) teaches the practice of sending indications 
comprising "net positions" amongst the parties to a transaction some of which are 
reversible, [see Abstract generally, e.g. between computers of banks and payment 
network]. Net positions (i.e. acknowledgments) ultimately indicate to the parties 
involved whether "the funds are good" and have been transferred as desired. In this vein, 
Hilt et al ('206) also contemplates "adherence of the participants to pre-agreed protocols" 
[column 12, line 46-47]. Here, Tsuda ('785) as well as the Niemi reference discussed in 
the remarks section above support the use of DIAMETER protocol for "various 
purposes". As such, it would have been obvious to one of ordinary skill in the art, at the 
time of Applicant's invention, to modify Hilt et al ('206) to include an acknowledging 
unit (e.g. sending unit) configured to return an acknowledgement to the network element 
wherein the acknowledgement is based on the DIAMETER protocol. One would have 
been motivated to do so given that acknowledgments are common (e.g. statements by 
banks that transactions have been completed) and one would recognize the ability to 
tailor DIAMETER protocol for other purposes as desired [see Niemi reference of remarks 
section] via such structure. 

As per Claims 11 & 12 , Applicant invokes 35 U.S.C §1 12-6 th paragraph by (1) utilizing 
the phrase "means for", (2) modified by functional language, (3) without an indication of 
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sufficient structure, materials or acts to achieve those functions. In this vein, Claims 1 1 
& 12 would ordinarily be construed to cover the corresponding structure, material, or acts 
disclosed in the specification and equivalents thereof However, Applicant's 
specification does not describe any further structure, material or acts. As such, Examiner 
will interpret all claim limitations as reading on any prior art means which is capable of 
performing the specified functions under a broadest reasonable interpretation. 
As such, Examiner rejects said Claims under the same logic and evidence of Claims 9 & 
10 respectively above. 



Claim 2 is rejected under 35 U.S.C. 103(a) as being unpatentable over Hilt et al 
(5,465,206) in view of Tsuda [2002/0065785] and further in view of Tubinis [2003/0014367]. 
As per Claim 2 , Hilt et al ('206), as modified, teaches the method of Claim 1 above. 
However, neither Hilt et al ('206) nor Tsuda ('785) explicitly discloses said interacting is 
based on a multimedia application run on a multimedia application server provided in said communication 
network. Nevertheless, Tubinis ('367) teaches "a subscriber of a communications network" 
with "capabilities of the application and application server providing the service" of 
"multimedia content including audio, video, data or any combination thereof and the 
charging for such service, [see Abstract]. As such, it would have been obvious to one of 
ordinary skill in the art, at the time of Applicant's invention, to modify Hilt et al ('206) 
and Tsuda('785) to include said interacting involving credit transfers associated with 
multimedia applications run on a multimedia application server. One would have been 
motivated to do so given that implementation would require "using a multimedia control 
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protocol" which realizes "[r]eal-time [] charging" and updating of accounts, [see 
Abstract]. Tsuda ('785) supports/links DIAMETER protocol with payment for goods 
[paragraph 16] and transferring money between accounts [paragraph 69]. 



Claim 5 is rejected under 35 U.S.C. 103(a) as being unpatentable over Hilt et al 
(5,465,206) in view of Tsuda [2002/0065785] and further in view of Official Notice. 

As per Claim 5 , Hilt et al ('206), as modified, teaches the method of Claim 4 above. 
However, neither Hilt et al ('206) nor Tsuda ('785) explicitly discloses the DIAMETER 
request message is routed to said source based on said second attribute value pair identifying said source. 
Regardless, Official Notice was taken, uncontested, that it is old and well-established that 
banks (as associated with bank accounts) have routing numbers often represented in 
MICR lines. In line with the discussion in Claim 4 above, it would have been obvious to 
one of ordinary skill in the art, at the time of Applicant's invention, to modify Hilt et al 
('206) and Tsuda ('785) to include the routing of a request message via routing 
information associated with an attribute value pair which identifies the source of a 
deposit. One would have been motivated to do so because a routing number is the means 
for a service provider to direct payment requests (e.g. presentments) to the correct 
institution. Further, Hilt et al ('206) supports entities maintaining a "look up table for 
consumers]", which logically, will associate an attribute value pair to consumer 
information (e.g. account number at bank) and bank information (e.g. name, proper 
routing number). Accurate presentment is necessary for any funds transfer to take place. 
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Lastly, attribute value pairs were known to contain routing information relevant to 
Diameter requests [see Niemi discussion in remarks section above]. 

Conclusion 

THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). Applicant has made substantive amendments in 
particular to claims 9-12, however, Examiner maintains his same grounds of rejection and 
addresses the additional limitations. Examiner incorporates background knowledge/motivations 
from an evidentiary reference into his rejections. This reference was specifically cited by 
Applicant in his/her specification (i.e. page 8) as providing introduction/basics of DIAMETER 
protocol. It provides critical insight to the knowledge of one of ordinary skill at the time of 
Applicant's invention and supports Examiner's original contentions. 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1 .136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 
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Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to John D. Scarito whose telephone number is (571) 270-3448. The 
examiner can normally be reached on M-Th (7:30-5:00), Alternate F (7:30-4:00). 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Kambiz Abdi can be reached on (571) 272-6702. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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